或许在架构师的眼中这本书是一本工具书，但是对我来说它更多的是一本概念上的科普著作。很多软件工程的概念，在大学课程里云里雾里的，工作了很久再重新读一遍，还真有点李云龙读《孙子兵法》的意思。
毕业后第一份工作，当时的导师给我们这些新入行的小菜鸟说，“要学会设计”。而当时和在之后的很长一段时间中，我对设计的理解就是根据一个应用的需求文档，把它转化成我的软件设计文档，文档包括什么呢？核心流程的流程图、基本的类图和核心流程的时序图。评审通过后，再根据之前的设计来敲代码——其实就是一个很具象的从需求分解到代码实现的APP编写过程。具体的总是容易理解的，相同场景对号入座总是容易些。然而工作的年头越多，碰到的问题也就越多了起来。
- 业务变得复杂之后怎么解决，大型应用并不是一个人几张图就能思考清楚所有需求细节的
- 跳出手机应用的圈子，一个客户端-服务端-嵌入式端的大系统如何来描述，方案如何定才能更好满足需求，同样无法适应
- 团队协作，1+1怎样才能大于等于2，这种问题也不会在个人开发的角度有所顾及
这个时候自己总结出的野路子就没那么好用了，本书对这种困境有很大程度上的解脱作用。首先它从软件产出的整个过程上有了清晰明确的定义；其次，软件工程的相关概念，分析、建模的工具，都有所描述、有所示例，能够对工作中碰到的琢磨不透的概念有更合理的认知；再次，让思维更加抽象，没有必要把思维固化在客户端开发上，需要思考的是软件设计问题。最后，工作中用过的、听过的，各种工具、设计模式、编程经验，可以在整个新的概念中找到位置，也是个知识再整合的过程。
从名字上看，这本书是在描述如何设计一个恰如其分的架构。整体分两部分，第一部分主要定义架构等工程学的概念，并且推广作者以风险控制为核心条件来设计架构的理念；第二部分则是针对各个架构过程中涉及到的知识与方法做示例和介绍。简单说，第一部分讲道，后一部分授术。
阅读过程中，由于对软件工程基础概念缺乏认知，导致在具体案例中理解一些实例架构方法比较困难。思考过程是从实例本身反推出这种方法概念的作用，而不是先理解它是什么再看它如何运用，理解上难免回有偏差，同时也会影响对本书整体的理解。这是最为头疼的一点，也跟这些概念本身并没有一定之规有关系，当然也跟翻译有一定关系，整体上阅读速度要比《Android组件化架构》这种基础工具书慢上很多，需要深度思考的地方也很多。
下一篇会介绍一些具体的收获。
